Простые таблицы — это таблицы, которые создаются однократно путём получения данных при создании из одного или нескольких источников. Простая таблица является неизменяемой, так как документы не могут быть добавлены или удалены в течение её жизненного цикла. Возможно только обновление значений числовых атрибутов (включая MVA). Обновление данных возможно только путём пересоздания всей таблицы.

Простые таблицы доступны только в Plain режиме, и их определение состоит из объявления таблицы и одного или нескольких объявлений источников. Сбор данных и создание таблицы выполняются не сервером searchd, а вспомогательным инструментом indexer.

Indexer — это инструмент командной строки, который можно вызывать напрямую из командной строки или из shell-скриптов.

Он может принимать ряд аргументов при вызове, но также имеет несколько собственных настроек в конфигурационном файле Manticore.

В типичном сценарии indexer выполняет следующие действия:

• Получает данные из источника
• Строит простую таблицу
• Записывает файлы таблицы
• (Опционально) Информирует поисковый сервер о новой таблице, что запускает ротацию таблиц

Инструмент indexer используется для создания простых таблиц в Manticore Search. Его общий синтаксис:

indexer [OPTIONS] [table_name1 [table_name2 [...]]]

При создании таблиц с помощью indexer сгенерированные файлы таблиц должны иметь права, позволяющие searchd читать, записывать и удалять их. В случае официальных пакетов для Linux searchd работает под пользователем manticore. Поэтому indexer также должен запускаться под пользователем manticore:

sudo -u manticore indexer ...

Если вы запускаете searchd иначе, возможно, потребуется опустить sudo -u manticore. Просто убедитесь, что пользователь, под которым работает ваш экземпляр searchd, имеет права на чтение/запись для таблиц, созданных с помощью indexer.

Чтобы создать простую таблицу, нужно перечислить таблицу(ы), которые вы хотите обработать. Например, если в вашем файле manticore.conf содержатся сведения о двух таблицах, mybigindex и mysmallindex, вы можете выполнить:

sudo -u manticore indexer mysmallindex mybigindex

Вы также можете использовать подстановочные знаки для сопоставления имён таблиц:

• ? соответствует любому одному символу
• * соответствует любому количеству любых символов
• % соответствует отсутствию или любому одному символу

sudo -u manticore indexer indexpart*main --rotate

Коды выхода indexer следующие:

• 0: всё прошло успешно
• 1: возникла проблема при индексации (и если был указан --rotate, он был пропущен) или операция выдала предупреждение
• 2: индексация прошла успешно, но попытка --rotate не удалась

Вы также можете запустить indexer с помощью следующего файла юнита systemctl:

systemctl start --no-block manticore-indexer

Или, если хотите построить конкретную таблицу:

systemctl start --no-block manticore-indexer@specific-table-name

Используйте команду systemctl set-environment INDEXER_CONFIG для запуска Indexer с пользовательской конфигурацией, которая заменяет настройки по умолчанию.

Команда systemctl set-environment INDEXER_ARGS позволяет добавить пользовательские параметры запуска для Indexer. Полный список параметров командной строки смотрите здесь.

Например, чтобы запустить Indexer в тихом режиме, выполните:

systemctl set-environment INDEXER_ARGS='--quiet'
systemctl restart manticore-indexer

Чтобы отменить изменения, выполните:

systemctl set-environment INDEXER_ARGS=''
systemctl restart manticore-indexer

• --config <file> (-c <file> для краткости) указывает indexer использовать указанный файл в качестве конфигурации. Обычно он ищет manticore.conf в каталоге установки (например, /etc/manticoresearch/manticore.conf), затем в текущем каталоге, в котором вы вызываете indexer из shell. Это особенно полезно в общих средах, где бинарные файлы установлены в глобальную папку, например /usr/bin/, но вы хотите предоставить пользователям возможность создавать свои собственные настройки Manticore или запускать несколько экземпляров на одном сервере. В таких случаях вы можете позволить им создавать свои собственные файлы manticore.conf и передавать их indexer с помощью этой опции. Например:

  sudo -u manticore indexer --config /home/myuser/manticore.conf mytable

• --all указывает indexer обновить все таблицы, перечисленные в manticore.conf, вместо указания отдельных таблиц. Это полезно в небольших конфигурациях или для заданий cron или обслуживания, когда весь набор таблиц пересоздаётся каждый день, неделю или в другой подходящий период. Обратите внимание, что поскольку --all пытается обновить все найденные таблицы в конфигурации, он выдаст предупреждение, если встретит RealTime таблицы, и код выхода команды будет 1, а не 0, даже если простые таблицы завершились без проблем. Пример использования:

  sudo -u manticore indexer --config /home/myuser/manticore.conf --all

• --rotate используется для ротации таблиц. Если у вас нет ситуации, когда можно отключить функцию поиска без неудобств для пользователей, вам почти наверняка нужно будет держать поиск запущенным во время индексации новых документов. --rotate создаёт вторую таблицу, параллельную первой (в том же месте, просто с включением .new в имена файлов). После завершения indexer уведомляет searchd отправкой сигнала SIGHUP, и searchd пытается переименовать таблицы (переименовывая существующие с добавлением .old и переименовывая .new в их место), а затем начинает обслуживать из новых файлов. В зависимости от настройки seamless_rotate может быть небольшая задержка перед возможностью поиска в новых таблицах. Если одновременно ротируются несколько таблиц, связанных отношениями killlist_target, ротация начнётся с таблиц, которые не являются целями, и закончится таблицами в конце цепочки целей. Пример использования:

  sudo -u manticore indexer --rotate --all

• --quiet указывает indexer не выводить ничего, кроме ошибок. Это в основном используется для заданий типа cron или других скриптов, где вывод не важен или не нужен, кроме случаев ошибок. Пример использования:

  sudo -u manticore indexer --rotate --all --quiet

• --noprogress не отображает детали прогресса по мере их появления. Вместо этого итоговые данные о статусе (например, количество проиндексированных документов, скорость индексации и так далее) выводятся только по завершении индексации. В случаях, когда скрипт не запускается в консоли (или 'tty'), этот параметр включен по умолчанию. Пример использования:

  sudo -u manticore indexer --rotate --all --noprogress

• --buildstops <outputfile.text> <N> просматривает исходную таблицу, как если бы она индексировалась, и создает список терминов, которые индексируются. Другими словами, он создает список всех поисковых терминов, которые становятся частью таблицы. Обратите внимание, что таблица при этом не обновляется, данные просто обрабатываются, как при индексации, включая выполнение запросов, определенных с помощью sql_query_pre или sql_query_post. В outputfile.txt будет содержаться список слов, по одному на строку, отсортированных по частоте с наиболее частыми первыми, а N задает максимальное количество слов в списке. Если N достаточно велик, чтобы охватить все слова в таблице, будет возвращено только столько слов. Такой словарь может использоваться для функций клиентских приложений, связанных с функционалом "Вы имели в виду…", обычно в сочетании с --buildfreqs, описанным ниже. Пример:

  sudo -u manticore indexer mytable --buildstops word_freq.txt 1000

  Это создаст файл в текущем каталоге word_freq.txt с 1000 наиболее часто встречающимися словами в 'mytable', упорядоченными по убыванию частоты. Обратите внимание, что файл будет относиться к последней проиндексированной таблице, если указано несколько таблиц или --all (то есть к последней в конфигурационном файле).

• --buildfreqs работает вместе с --buildstops (игнорируется, если --buildstops не указан). Поскольку --buildstops предоставляет список слов, используемых в таблице, --buildfreqs добавляет количество их вхождений в таблицу, что полезно для определения, следует ли считать некоторые слова стоп-словами, если они слишком распространены. Это также помогает при разработке функций "Вы имели в виду…", где нужно знать, насколько одно слово встречается чаще другого, похожего. Например:

  sudo -u manticore indexer mytable --buildstops word_freq.txt 1000 --buildfreqs

  Это создаст word_freq.txt, как описано выше, но после каждого слова будет указано количество его вхождений в таблицу.

• --merge <dst-table> <src-table> используется для физического слияния таблиц, например, если у вас есть схема main+delta, где основная таблица редко меняется, а дельта-таблица часто перестраивается, и --merge используется для объединения двух таблиц. Операция идет справа налево — содержимое src-table анализируется и физически объединяется с содержимым dst-table, а результат остается в dst-table. В псевдокоде это можно выразить как: dst-table += src-table Пример:

  sudo -u manticore indexer --merge main delta --rotate

  В приведенном примере, где main — это основная, редко изменяемая таблица, а delta — более часто изменяемая, вы можете использовать эту команду для вызова indexer, чтобы объединить содержимое delta с main и выполнить ротацию таблиц.

• --merge-dst-range <attr> <min> <max> применяет фильтр диапазона при слиянии. Конкретно, поскольку слияние применяется к целевой таблице (в рамках --merge и игнорируется, если --merge не указан), indexer также фильтрует документы, попадающие в целевую таблицу, и только документы, проходящие через заданный фильтр, окажутся в итоговой таблице. Это может использоваться, например, в таблице с атрибутом 'deleted', где 0 означает 'не удален'. Такая таблица может быть объединена с помощью:

  sudo -u manticore indexer --merge main delta --merge-dst-range deleted 0 0

  Все документы, помеченные как удаленные (значение 1), будут удалены из вновь объединенной целевой таблицы. Этот параметр можно указывать несколько раз в командной строке, чтобы добавить последовательные фильтры к слиянию, все из которых должны быть выполнены, чтобы документ стал частью итоговой таблицы.

• --merge-killlists (и его короткий псевдоним --merge-klists) изменяет способ обработки списков удаления (kill lists) при слиянии таблиц. По умолчанию оба списка удаления отбрасываются после слияния. Это поддерживает наиболее типичный сценарий слияния main+delta. При включении этой опции списки удаления обеих таблиц объединяются и сохраняются в целевой таблице. Обратите внимание, что список удаления исходной (delta) таблицы всегда используется для подавления строк из целевой (main) таблицы.

• --keep-attrs позволяет повторно использовать существующие атрибуты при переиндексации. При перестроении таблицы для каждого нового id документа проверяется наличие в "старой" таблице, и если он уже существует, его атрибуты переносятся в "новую" таблицу; если не найден, используются атрибуты из новой таблицы. Если пользователь обновил атрибуты в таблице, но не в исходных данных, используемых для таблицы, все обновления будут потеряны при переиндексации; использование --keep-attrs позволяет сохранить обновленные значения атрибутов из предыдущей таблицы. Можно указать путь к файлам таблицы, который будет использоваться вместо пути из конфигурации:

  sudo -u manticore indexer mytable --keep-attrs=/path/to/index/files

• --keep-attrs-names=<attributes list> позволяет указать атрибуты для повторного использования из существующей таблицы при переиндексации. По умолчанию все атрибуты из существующей таблицы повторно используются в новой таблице:

  sudo -u manticore indexer mytable --keep-attrs=/path/to/table/files --keep-attrs-names=update,state

• --dump-rows <FILE> сохраняет строки, полученные из SQL-источника(ов), в указанный файл в синтаксисе, совместимом с MySQL. Полученные дампы являются точным представлением данных, как они получены indexer, и могут помочь воспроизвести проблемы, возникающие во время индексации. Команда выполняет получение данных из источника и создает как файлы таблиц, так и файл дампа.

• --print-rt <rt_index> <table> выводит полученные данные из источника в виде INSERT-запросов для таблицы реального времени. Первые строки дампа будут содержать поля и атрибуты реального времени (как отражение полей и атрибутов обычной таблицы). Команда выполняет получение данных из источника и создает как файлы таблиц, так и вывод дампа. Команду можно использовать как sudo -u manticore indexer -c manticore.conf --print-rt indexrt indexplain > dump.sql. Поддерживаются только источники на основе SQL. MVAs не поддерживаются.

• --sighup-each полезен, когда вы перестраиваете много больших таблиц и хотите, чтобы каждая из них была как можно скорее загружена в searchd. С --sighup-each indexer отправит сигнал SIGHUP в searchd после успешного завершения работы с каждой таблицей. (По умолчанию отправляется один SIGHUP после построения всех таблиц).

• --nohup полезен, когда вы хотите проверить таблицу с помощью indextool перед фактической загрузкой. indexer не отправит SIGHUP, если эта опция включена. Файлы таблиц переименовываются в .tmp. Используйте indextool для переименования файлов таблиц в .new и загрузки их. Пример использования:

  sudo -u manticore indexer --rotate --nohup mytable
  sudo -u manticore indextool --rotate --check mytable

• --print-queries выводит SQL-запросы, которые indexer отправляет в базу данных, вместе с событиями подключения и отключения SQL. Это полезно для диагностики и устранения проблем с SQL-источниками.

• --help (-h для краткости) выводит список всех параметров, которые можно вызвать в indexer.

• -v показывает версию indexer.

Вы также можете настроить поведение indexer в конфигурационном файле Manticore в разделе indexer:

indexer {
...
}

lemmatizer_cache = 256M

Размер кэша лемматизатора. Необязательно, по умолчанию 256K.

Наша реализация лемматизатора использует сжатый формат словаря, который позволяет балансировать между объемом памяти и скоростью. Он может либо выполнять лемматизацию на сжатых данных, используя больше CPU, но меньше RAM, либо распаковывать и предварительно кэшировать словарь частично или полностью, используя меньше CPU, но больше RAM. Директива lemmatizer_cache позволяет контролировать, сколько именно RAM может быть выделено для этого кэша распакованного словаря.

В настоящее время доступны только словари ru.pak, en.pak и de.pak. Это русские, английские и немецкие словари. Размер сжатого словаря примерно от 2 до 10 МБ. Обратите внимание, что словарь всегда находится в памяти. Размер кэша по умолчанию — 256 КБ. Допустимые размеры кэша — от 0 до 2047 МБ. Безопасно увеличивать размер кэша слишком высоко; лемматизатор будет использовать только необходимую память. Например, весь русский словарь распаковывается примерно до 110 МБ; поэтому установка lemmatizer_cache выше этого значения не повлияет на использование памяти. Даже если разрешено 1024 МБ для кэша, если нужно только 110 МБ, будет использовано только 110 МБ.

max_file_field_buffer = 128M

Максимальный размер адаптивного буфера для файлового поля в байтах. Необязательно, по умолчанию 8 МБ, минимум 1 МБ.

Буфер файлового поля используется для загрузки файлов, на которые ссылаются столбцы sql_file_field. Этот буфер адаптивен, начиная с 1 МБ при первом выделении и увеличиваясь в 2 раза, пока либо содержимое файла не будет загружено, либо не будет достигнут максимальный размер буфера, указанный директивой max_file_field_buffer.

Таким образом, если файловые поля не указаны, буфер не выделяется вообще. Если все файлы, загружаемые во время индексации, меньше (например) 2 МБ, а значение max_file_field_buffer равно 128 МБ, пиковое использование буфера все равно будет только 2 МБ. Однако файлы размером более 128 МБ будут полностью пропущены.

max_iops = 40

Максимальное количество операций ввода-вывода в секунду для ограничения I/O. Необязательно, по умолчанию 0 (без ограничений).

Опция, связанная с ограничением I/O. Она ограничивает максимальное количество операций ввода-вывода (чтение или запись) за любую секунду. Значение 0 означает отсутствие ограничений.

indexer может вызывать всплески интенсивных операций дискового ввода-вывода во время построения таблицы, и может быть желательно ограничить его активность на диске (и оставить ресурсы для других программ, работающих на той же машине, например searchd). Ограничение I/O помогает в этом. Оно работает, обеспечивая минимальную гарантированную задержку между последовательными операциями дискового ввода-вывода, выполняемыми indexer. Ограничение I/O может помочь уменьшить ухудшение производительности поиска, вызванное построением. Эта настройка неэффективна для других видов загрузки данных, например вставки данных в таблицу реального времени.

max_iosize = 1048576

Максимально допустимый размер операции ввода-вывода в байтах для ограничения I/O. Необязательно, по умолчанию 0 (без ограничений).

Опция, связанная с ограничением I/O. Она ограничивает максимальный размер файловой операции ввода-вывода (чтение или запись) для всех операций, выполняемых indexer. Значение 0 означает отсутствие ограничений. Чтения или записи, превышающие этот лимит, будут разбиты на несколько меньших операций и учитываться как несколько операций в настройке max_iops. На момент написания все вызовы I/O должны быть меньше 256 КБ (размер внутреннего буфера по умолчанию), поэтому значения max_iosize выше 256 КБ не должны влиять.

max_xmlpipe2_field = 8M

Максимально допустимый размер поля для источника типа XMLpipe2 в байтах. Необязательно, по умолчанию 2 МБ.

mem_limit = 256M
# mem_limit = 262144K # same, but in KB
# mem_limit = 268435456 # same, but in bytes

Plain table building RAM usage limit. Optional, default is 128 MB. Enforced memory usage limit that the indexer will not go above. Can be specified in bytes, or kilobytes (using K postfix), or megabytes (using M postfix); see the example. This limit will be automatically raised if set to an extremely low value causing I/O buffers to be less than 8 KB; the exact lower bound for that depends on the built data size. If the buffers are less than 256 KB, a warning will be produced.

Максимально возможный лимит — 2047M. Слишком низкие значения могут замедлить построение plain table, но 256M до 1024M должно быть достаточно для большинства, если не всех наборов данных. Установка слишком высокого значения может привести к тайм-аутам SQL сервера. Во время фазы сбора документов будут периоды, когда буфер памяти частично отсортирован и связь с базой данных не выполняется; и сервер базы данных может прервать соединение по тайм-ауту. Вы можете решить эту проблему либо увеличив тайм-ауты на стороне SQL сервера, либо уменьшив mem_limit.

on_file_field_error = skip_document

Как обрабатывать ошибки ввода-вывода в файловых полях. Необязательно, по умолчанию ignore_field. Когда возникает проблема с индексированием файла, на который ссылается файловое поле (sql_file_field), indexer может либо обработать документ, предполагая пустое содержимое в этом конкретном поле, либо пропустить документ, либо полностью завершить индексирование с ошибкой. Директива on_file_field_error контролирует это поведение. Возможные значения:

• ignore_field, обработать текущий документ без поля;
• skip_document, пропустить текущий документ, но продолжить индексирование;
• fail_index, завершить индексирование с сообщением об ошибке.

Проблемы, которые могут возникнуть: ошибка открытия, ошибка размера (файл слишком большой) и ошибка чтения данных. Предупреждающие сообщения о любой проблеме будут выдаваться всегда, независимо от фазы и настройки on_file_field_error.

Обратите внимание, что при on_file_field_error = skip_document документы будут игнорироваться только если проблемы обнаружены на ранней фазе проверки, и не во время фактического разбора файла. indexer откроет каждый указанный файл и проверит его размер перед началом работы, а затем откроет его снова при фактическом разборе. Поэтому, если файл исчезнет между этими двумя попытками открытия, документ всё равно будет проиндексирован.

write_buffer = 4M

Размер буфера записи, в байтах. Необязательно, по умолчанию 1MB. Буферы записи используются для записи как временных, так и окончательных файлов таблиц при индексировании. Большие буферы уменьшают количество необходимых операций записи на диск. Память для буферов выделяется дополнительно к mem_limit. Обратите внимание, что будет выделено несколько (в настоящее время до 4) буферов для разных файлов, что пропорционально увеличивает использование ОЗУ.

ignore_non_plain = 1

ignore_non_plain позволяет полностью игнорировать предупреждения о пропуске не-plain таблиц. По умолчанию 0 (не игнорировать).

Существует два подхода к планированию запусков indexer. Первый способ — классический метод с использованием crontab. Второй способ — использование таймера systemd с пользовательским расписанием. Чтобы создать файлы юнитов таймера, их нужно поместить в соответствующий каталог, где systemd ищет такие файлы юнитов. В большинстве дистрибутивов Linux этот каталог обычно /etc/systemd/system. Вот как это сделать:

1. Создайте файл юнита таймера для вашего пользовательского расписания:

   cat << EOF > /etc/systemd/system/manticore-indexer@.timer
   [Unit]
   Description=Run Manticore Search's indexer on schedule
   [Timer]
   OnCalendar=minutely
   RandomizedDelaySec=5m
   Unit=manticore-indexer@%i.service
   [Install]
   WantedBy=timers.target
   EOF

   Подробнее о синтаксисе и примерах OnCalendar можно найти здесь.

2. Отредактируйте юнит таймера под свои нужды.

3. Включите таймер:

   systemctl enable manticore-indexer@idx1.timer

4. Запустите таймер:

   systemctl start manticore-indexer@idx1.timer

5. Повторите шаги 2-4 для любых дополнительных таймеров.

Manticore Search позволяет извлекать данные из баз данных с помощью специализированных драйверов или ODBC. Текущие драйверы включают:

• mysql - для баз данных MySQL/MariaDB/Percona MySQL
• pgsql - для базы данных PostgreSQL
• mssql - для базы данных Microsoft SQL
• odbc - для любой базы данных, которая принимает подключения через ODBC

Для извлечения данных из базы данных необходимо настроить источник с типом, соответствующим одному из перечисленных выше. Источник требует информации о том, как подключиться к базе данных, и запроса, который будет использоваться для извлечения данных. Также можно задать дополнительные предварительные и последующие запросы — либо для настройки параметров сессии, либо для выполнения задач до/после извлечения. Источник также должен содержать определения типов данных для извлекаемых столбцов.

Определение источника должно содержать настройки подключения, включая хост, порт, учетные данные пользователя или специфические настройки драйвера.

Хост сервера базы данных для подключения. Обратите внимание, что библиотека клиента MySQL выбирает, подключаться ли по TCP/IP или через UNIX-сокет, основываясь на имени хоста. В частности, "localhost" заставит использовать UNIX-сокет (это режим по умолчанию и обычно рекомендуемый), а "127.0.0.1" заставит использовать TCP/IP.

IP-порт сервера для подключения. Для mysql по умолчанию 3306, для pgsql — 5432.

SQL-база данных, которая будет использоваться после установления подключения для выполнения дальнейших запросов.

Имя пользователя для подключения.

Пароль пользователя для подключения. Если пароль содержит # (который может использоваться для добавления комментариев в конфигурационный файл), его можно экранировать с помощью \.

Имя UNIX-сокета для подключения к локальным серверам баз данных. Обратите внимание, что использование этого значения зависит от настройки sql_host.

sql_sock = /var/lib/mysql/mysql.sock

Флаги подключения клиента MySQL. Необязательно, значение по умолчанию — 0 (не устанавливать флаги).

Эта опция должна содержать целочисленное значение, равное сумме флагов. Значение будет передано в mysql_real_connect() без изменений. Флаги перечислены в include-файле mysql_com.h. Особенно интересные флаги в контексте индексирования с их значениями:

• CLIENT_COMPRESS = 32; может использовать протокол сжатия
• CLIENT_SSL = 2048; переключение на SSL после рукопожатия
• CLIENT_SECURE_CONNECTION = 32768; новая аутентификация 4.1 Например, можно указать 2080 (2048+32) для использования сжатия и SSL, или 32768 для использования только новой аутентификации. Изначально эта опция была введена для возможности использования сжатия, когда индексатор и mysqld находятся на разных хостах. Сжатие на каналах 1 Гбит/с скорее всего ухудшит время индексирования, хотя и уменьшит сетевой трафик, как в теории, так и на практике. Однако включение сжатия на каналах 100 Мбит/с может значительно улучшить время индексирования (сообщалось об улучшении до 20-30% от общего времени индексирования). Ваши результаты могут отличаться.

mysql_connect_flags = 32 # enable compression

• mysql_ssl_cert - путь к SSL-сертификату
• mysql_ssl_key - путь к файлу SSL-ключа
• mysql_ssl_ca - путь к сертификату CA

unpack_mysqlcompress_maxsize = 1M

Столбцы для распаковки с использованием алгоритма MySQL UNCOMPRESS(). Множественное значение, необязательно, значение по умолчанию — пустой список столбцов.

Столбцы, указанные с помощью этой директивы, будут распакованы индексатором с использованием модифицированного алгоритма zlib, применяемого в функциях MySQL COMPRESS() и UNCOMPRESS(). При индексировании на другой машине, отличной от базы данных, это позволяет разгрузить базу данных и сэкономить сетевой трафик. Эта функция доступна только если zlib и zlib-devel были доступны во время сборки.

unpack_mysqlcompress = body_compressed
unpack_mysqlcompress = description_compressed

По умолчанию для распаковки данных используется буфер размером 16M. Это можно изменить, установив unpack_mysqlcompress_maxsize.

При использовании unpack_mysqlcompress, из-за особенностей реализации, невозможно определить необходимый размер буфера по сжатым данным. Поэтому буфер должен быть выделен заранее, и распакованные данные не могут превышать размер буфера.

unpack_zlib = col1
unpack_zlib = col2

Столбцы для распаковки с использованием zlib (также известного как deflate или gunzip). Множественное значение, необязательно, значение по умолчанию — пустой список столбцов. Применяется только к типам источников mysql и pgsql.

Столбцы, указанные с помощью этой директивы, будут распакованы indexer с использованием стандартного алгоритма zlib (называемого deflate и также реализованного в gunzip). При индексировании на другой машине, отличной от базы данных, это позволяет разгрузить базу данных и сэкономить сетевой трафик. Эта функция доступна только если zlib и zlib-devel были доступны во время сборки.

Флаг аутентификации Windows MS SQL. Определяет, использовать ли учетные данные текущего вошедшего в систему Windows-пользователя для аутентификации при подключении к MS SQL Server.

mssql_winauth = 1

Источники, использующие ODBC, требуют наличия строки DSN (Data Source Name), которая может быть установлена с помощью odbc_dsn.

odbc_dsn = Driver={Oracle ODBC Driver};Dbq=myDBName;Uid=myUsername;Pwd=myPassword

Обратите внимание, что формат зависит от конкретного используемого драйвера ODBC.